Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@next-env.d.ts`:
- Line 3: The import path in next-env.d.ts uses an incorrect and unstable path
by including `/dev` in the route. Remove `/dev` from the import statement so
that it reads `import "./.next/types/routes.d.ts";` instead of `import
"./.next/dev/types/routes.d.ts";`. This uses the official stable proxy file path
that Next.js maintains for proper compatibility across environments. Note that
since next-env.d.ts is auto-generated, Next.js may revert this change
automatically on the next run.

In `@server/lib/requestSort.ts`:
- Around line 103-180: The sortRequestsByTmdbField function has complex sorting
logic including media deduplication, concurrent TMDB fetching, cache handling,
and field-specific comparisons, but currently lacks unit test coverage. Create
comprehensive unit tests that verify: deduplication by type-tmdbId key (ensuring
TMDB data is fetched only once per unique media), missing cache entry handling
(items without TMDB data sort consistently by ID), each of the four sort fields
(title, popularity, voteAverage, releaseDate) sort correctly in both ascending
and descending directions, tie-breaking logic (equal values ordered
deterministically by request ID), and error resilience (TMDB fetch failures
handled gracefully). Mock the TheMovieDb class and fetchMediaSortCache function
to simulate various success and failure scenarios for testing.
- Around line 145-155: The sortRequestsByTmdbField function in
server/lib/requestSort.ts has complex logic for TMDB data fetching,
deduplication, error handling, and sorting but lacks any unit test coverage in
server/lib/requestSort.test.ts. Add comprehensive test cases covering: the
scenario where items without cached TMDB data are placed at the end,
deduplication by type-tmdbId key, sorting by each field (popularity,
voteAverage, releaseDate, title) in both ascending and descending directions,
tie-breaking behavior using request.id, and error handling when TMDB API calls
fail.

---

Nitpick comments:
In `@server/lib/requestSort.ts`:
- Around line 57-64: The getRequestSortColumn function currently accepts the
broad RequestSortField type parameter, but it is only called with 'added' and
'modified' values according to the actual usage context. Narrow the parameter
type from RequestSortField to a union type that only includes 'added' |
'modified' to make the function contract clearer and prevent invalid calls from
being compiled. Update the switch statement's default case accordingly since
those are now the only expected values.

In `@server/routes/request.ts`:
- Around line 174-183: Add observability to the TMDB sort path in the
isTmdbRequestSort block to monitor real-world performance impact. After loading
all records with query.getMany() and before calling sortRequestsByTmdbField, add
logging that triggers when the request count exceeds a reasonable threshold
(e.g., 1000 records). This will help identify cases where the in-memory sorting
of large datasets is causing performance issues without blocking the
functionality.